Add: READMEs for the a5 bgemm and deferred-completion demos - #1576
Conversation
The three a5 examples with no a2a3 counterpart to read instead. `bgemm` keeps its kernel in `kernels/mix/` rather than `kernels/aic/` plus `kernels/aiv/`, and that directory name is the example. One source is registered as two incores with different core_types; `__DAV_CUBE__` compiles the TLOAD/TMATMUL/TPUSH half and `__DAV_VEC__` the TPOP/TADD/TSTORE half, both over the same three-tensor args[]. The matmul product moves between them through VEC_FIFO and never reaches GM — only the accumulator C round-trips. a2a3's `benchmark_bgemm` computes the same thing with separate sources and a GM round trip, so the two are not ports of each other. `urma_deferred_completion_demo` and `sdma_async_completion_demo` run an identical two-rank protocol over different transports; `kernel_consumer.cpp` is byte-identical between them, leaving the transport as the only variable. Both are gated behind a workspace overlay that defaults OFF, and the two overlays are mutually exclusive in one build — `CommContext` exposes a single workSpace/workSpaceSize pair, so the CMakeLists raises a FATAL_ERROR if both are on. A stock build therefore skips both tests even on a5 silicon: a green CI run is not coverage of either path. Each README gives the two-step invocation, since the env var is read once by runtime_builder.py to compile the overlay in and once by the test's skipif. The a5 index gains those facts, and its `paged_attention_unroll_manual_scope` row is corrected the same way the a2a3 index was in hw-native-sys#1571: the kernels are rewritten (softmax_prepare changes 269 lines against a 149-line original), so it is a second implementation rather than manual scope plus an unroll. The manual_scope row now records that its four kernels are byte-identical to the baseline's and only the orchestration differs, 52 lines of 288. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 15 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
The three a5 examples with no a2a3 counterpart to read instead.
bgemm— one source, two cores, no GM round tripIt keeps its kernel in
kernels/mix/rather thankernels/aic/+kernels/aiv/, and that directory name is the example. The same source is registered as two incores with differentcore_types:func_idcore_typeGEMM)aic__DAV_CUBE__TLOAD,TMATMUL,TPUSHADD)aiv__DAV_VEC__TPOP,TADD,TSTOREBoth see the same three-tensor
args[]. The matmul product moves between the halves throughVEC_FIFOand never reaches GM — only the accumulatorCround-trips, once perGRID_Kiteration.a2a3's
benchmark_bgemmcomputes the same thing with separate sources and a GM round trip, and exists to sweep shapes. The two are not ports of each other, which the READMEs now say on both sides.urma_/sdma_deferred_completion_demo— same protocol, two transportskernel_consumer.cppis byte-identical between the two directories, so the transport is the only variable — the useful property when choosing between them. What differs: the transfer kernel, its completion header, and the build flag.The load-bearing constraint is in
src/a5/platform/onboard/host/CMakeLists.txt:Both default
OFFand one build can carry one overlay, not both. So a stock build skips both tests even on a5 silicon — a green CI run is not coverage of either path, which seemed worth stating plainly. Each README gives the two-step invocation, since the env var is read twice for different reasons:simpler_setup/runtime_builder.py:381-386forwards it to CMake so the overlay compiles in, and the test'sskipifreads it from the environment.Index corrections
The a5 index carried the same wrong one-liner the a2a3 one did before #1571:
paged_attention_unroll_manual_scopewas "Manual scope plus loop unrolling". The kernels are rewritten —aiv_softmax_prepare.cppchanges 269 lines against a 149-line original — so it is a second implementation.paged_attention_manual_scopenow records that its four kernels are byte-identical to the baseline's and only the orchestration differs, 52 lines of 288.Testing
markdownlint-cli2 --config tests/lint/.markdownlint.yaml— 0 errors on all four fileskernels/mix/kernel_bgemm.cppand the twoincoresentries intest_bgemm.py;"mix"confirmed as a live sentinel indeps_viewer.py,l0_swimlane.py,sched_overhead_analysis.pysrc/a5/platform/onboard/host/CMakeLists.txt:47-53; env forwarding fromsimpler_setup/runtime_builder.py:381-386;kernel_consumer.cppidentity viadiff -qdiff | grep -c '^[<>]'Docs only; no code, test, or build files touched.